Skip to content

[Security 19] security posture: SECURITY.md, CodeQL, secret scan, Scorecard - #246

Open
amal66 wants to merge 1 commit into
Open-Legal-Products:mainfrom
amal66:olp-pr/security-posture
Open

[Security 19] security posture: SECURITY.md, CodeQL, secret scan, Scorecard#246
amal66 wants to merge 1 commit into
Open-Legal-Products:mainfrom
amal66:olp-pr/security-posture

Conversation

@amal66

@amal66 amal66 commented Jul 23, 2026

Copy link
Copy Markdown
Collaborator

This picks up the security-posture pieces that #227 (npm audit gate, security ESLint, dependabot) doesn't cover. No overlap: #227 gates dependencies and code patterns on each PR; this PR adds a disclosure policy and three scanners.

What's in it

  • SECURITY.md — tells a researcher how to reach you privately (GitHub's built-in reporting, no email needed), what to expect (acknowledgment within 7 days — it says plainly you're a solo maintainer), and what's in scope. Since Mike is an LLM legal product, prompt-injection reports are explicitly invited.
  • CodeQL (codeql.yml) — GitHub's own static analyzer, on every PR, push to main, and weekly. Both backend/ and frontend/ are interpreted TypeScript, so it needs no build step. Findings appear under the Security tab, not as PR noise.
  • Secret scan (gitleaks.yml + .gitleaks.toml) — scans the entire git history for committed credentials on every PR and push. It deliberately does not use the official gitleaks-action, which requires a paid license key for organization repos — instead it downloads the pinned 8.30.1 binary and verifies its sha256 before running. I ran it over all 551 commits locally: the only hits were fake keys in tests and docs examples (verified by hand, each one allowlisted with a comment in .gitleaks.toml), so the check starts green and any new secret fails CI.
  • OpenSSF Scorecard (scorecard.yml) — a weekly automated report card on the repo's own security hygiene (branch protection, workflow permissions, etc.), published to the public OpenSSF database.

Maintainer action required (repo Settings, ~2 minutes)

  1. Enable private vulnerability reporting: Settings → Code security → "Private vulnerability reporting" → Enable. Without this, the "Report a vulnerability" button SECURITY.md points to doesn't exist.
  2. Enable secret scanning + push protection: Settings → Code security → enable both "Secret scanning" and "Push protection". This is GitHub's server-side layer; the gitleaks workflow complements it, but push protection is the one that stops a secret before it lands in history.
  3. Optional, after the first Scorecard run on main: add the badge to README —
    [![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/Open-Legal-Products/mike/badge)](https://scorecard.dev/viewer/?uri=github.com/Open-Legal-Products/mike)

Notes

  • CodeQL and Scorecard results go to the Security tab (code scanning); only the gitleaks job blocks PRs directly.
  • codeql-action is pinned to the v3 major; Scorecard to v2.4.3.
  • Merge order vs [Security 11] Server-side hardening pack  #227 doesn't matter — the two touch disjoint files.

🤖 Generated with Claude Code

@CLAassistant

CLAassistant commented Jul 23, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@github-advanced-security

Copy link
Copy Markdown

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

  • The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
  • Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
  • You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

Public-repo security posture on top of PR Open-Legal-Products#227's audit/eslint/dependabot
gates:

- SECURITY.md: private vulnerability reporting via the Security tab,
  7-day acknowledgment (solo maintainer), self-hosted + LLM
  prompt-injection scope notes. main-only support (no release tags yet).
- codeql.yml: javascript-typescript analysis with build-mode: none
  (interpreted TS, no build needed) on PRs, main, and a weekly cron.
- gitleaks.yml: full-history secret scan using a sha256-verified pinned
  release binary instead of gitleaks-action (which needs a paid license
  for org repos). .gitleaks.toml allowlists hand-verified fake secrets
  (test fixtures, docs placeholders, the public supabase-demo anon key);
  a local run over all 551 commits is clean with this config.
- scorecard.yml: OpenSSF Scorecard on main + weekly cron with
  publish_results: true.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@amal66
amal66 force-pushed the olp-pr/security-posture branch from 5e98f07 to 9e2eff9 Compare July 25, 2026 21:31
@amal66
amal66 requested a review from willchen96 July 26, 2026 14:09
@willchen96

Copy link
Copy Markdown
Collaborator

Thanks for adding this security baseline. Private vulnerability reporting is now enabled, so that concern is resolved. I found four remaining issues before merge:

  1. Hosted-service scope: SECURITY.md says there is no hosted service, but the official Mike website offers a cloud version at app.mikeoss.com. The third-party-deployment exclusion should apply only to independent self-hosted installations.

  2. Workflow action pinning: The new workflows reference actions through movable tags such as @v3, @v4, and @v2.4.3. This is particularly concerning in the Scorecard job because it receives id-token: write and security-events: write. GitHub recommends pinning actions to verified full commit SHAs, the only immutable reference format. Please pin all new uses: entries and retain the release version in a comment for Dependabot.

  3. Overbroad gitleaks exclusions: The path allowlists suppress every future secret found in those files, not just the known fake fixtures. A real credential added later to one of the security tests or documentation files would pass the scan. Please allowlist the exact fixture strings or specific historical commits instead of entire paths.

  4. Incorrect release statement: The repository already has tags v0.1.0 through v0.4.0, all predating this PR. If only main receives security fixes, the policy should explicitly mark those tagged versions as unsupported rather than saying no tagged releases exist.

The branch is behind current main, but I confirmed that it merges cleanly. I also verified the gitleaks 8.30.1 checksum and successfully scanned the merged repository with no existing leaks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants